🔪 Delete Ripper implementation #784
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As of now, the difference between the Ripper and Prism implementations is quite small, and many of the diffs that are generated are mostly fixes for bugs that exist only in Ripper (or are sufficiently rare and don't affect the runtime behavior that I think we can live with them). Given how small the diff is, I don't think it's worth having a version with the
--prismflag, and instead we should just shift over to Prism being the main implementation for the next release we cut. (There are probably a few small things to get in before we cut a release, like a bit more cleanup and #740, but I think we should cut one reasonably soon after that.)The vast majority of the deletions are of course the Ripper tree types, deserialization code, and the Ruby VM checkout. There's also some deletions of token types, error types, and parser state methods that were only used by the Ripper implementation and were flagged by the compiler as dead code. There's more cleanup that we could do after this, but I wanted to keep this at a reasonable size, so I figure there would be follow-ons later.
I've done my best to break this up into commits that are somewhat-related, but I sort of worked backwards from the fully-deleted change, so each commit is not perfectly self-contained. It's mostly just to avoid having a single 8k line deletion commit.